Application List
Volume Number: 1
Issue Number: 7
Column Tag: standard file
Available Application List 
By Chris Yerga
A few weeks ago I was compiling a disk of my favorite games for a friend of mine.
Disk space being as valuable as it is, the Finder’s use of close to 50K of disk space
seemed a terrible waste on a disk containing files that would probably never be
manipulated in any way. Armed with my copy of Inside Macintosh, I set out to correct
this injustice. My goal was to write a short program that would present the user with
a list of the available applications and allow him to execute the one of his choosing. As
is usually the case when I set out to write a program, I found that what seems at first
to be an arduous task (up to this point I had never tried to access the disk drive and the
file directory) is actually quite simple when full advantage is taken of the Mac’s built
in routines. This article will concern itself with two such routines: the Standard File
routine and the Launch facility.
Working according to the flow of the program, our first concern is to list the
available applications and allow the user to select the one he wants to execute. Anyone
who has ever opened a document from an application should be familiar with the
Standard Get File dialog box [See BASIC column for an introduction to Standard File
dialog box]. This standard method of opening a file is quite simple to implement
through the convenience of the Package Manager. The package manager allows an
application to call one of several “packages” -- short specialized routines kept in the
System file -- from its main code. This saves the programmer from having to write
code to perform the tasks that are provided for by the Package Manager. There are
packages for opening files, saving files, initializing disks, and performing
Binary/Hex conversion among others.
The package that we are going to use is called the Standard Get File package. It
lists all the files of a certain filetype that are on a disk and allows the user to choose
one of them. As programmers, virtually all that we are required to do is tell the
package manager what filetype(s) that we want listed and where to put the resulting
information. The PM takes care of the rest: it creates the dialog box, reads the disk
directory, handles events, and stores the input that it gets from the user. This is
exactly what we want, so our task is simplified immensely by this routine. However,
if we did need the PM to function a bit differently, it has provisions for designing
custom dialog boxes and performing special event handling tasks.
Page 13 of the Package Manager Programmer’s Guide portion of Inside Macintosh
describes the standard get file procedure’s PASCAL interface as follows:
Procedure SFGetFile (where: Point; prompt: Str255; fileFilter:
ProcPtr; numTypes: INTEGER; typeList: SFListPtr; dlgHook: ProcPtr;
VAR reply: SFReply);
From assembly language, the first value that we need to push is where, which
describes the top lefthand point at which the dialog box will be drawn. A bit of
experimentation convinced me that (80,86) would serve our purpose well. The next
variable, prompt, is not used by the current PM; however, older versions did
require it to be passed, and so the PM accepts it to insure compatability with older
programs. FileFilter is used by applications that want to determine for themselves
which files to display in the dialog box. We will pass NIL for this variable, because
we would rather have the PM do it for us. NumTypes tells the PM how many different
filetypes we want displayed. In our case this value is 1, since we only want
applications displayed. Next, we push typeList, a pointer to the list of filetypes to be
displayed. DlgHook is used by applications that need to draw a custom dialog box.
Again, since the standard dialog box suits our needs, we will pass NIL. Finally, VAR
SFReply points to the standard file reply record, a data structure through which the
PM communicates with the calling application. The assembly language implementation
looks like this:
SFGetFile From Assembly
MOVE.W #86,-(SP) ;Y coord. of where
MOVE.W #80,-(SP) ;X coord. of where
PEA ‘Prompt’ ;prompt: unused, but
;we need to pass a ;string to keep the
;Package Manager ;happy
CLR.L -(SP) ;fileFilter: unused,
;so we pass NIL
MOVE.W #1,-(SP) ;numTypes: there is
;only 1 filetype in
;our list
PEA TypeList ;typeList: points to
;our list of filetypes
CLR.L -(SP) ;dlgHook: unused, so
;we pass NIL
PEA SFReply ;SFReply: points to
;the Reply Record
The reply record contains information such as the filename, filetype, the
volume where the file can be found, etc. Its structure, as described in Inside
Macintosh is shown in figure 1.
The first variable, good, tells whether or not valid data is in the reply record.
If it is FALSE, then the user hit the cancel button or for some other reason, the data
should be ignored. If TRUE, then the call was successful and the calling application can
process the data. Copy is unused; Inside Macintosh gives no explaination. The next
variable is fType, the 4 character filetype of the file selected. We do not need to look at
this, because it will always be ‘APPL’ -- the filetype for applications. VRefNum is
the volume reference number of the volume that contains the selected file. This is
needed in many file manager calls. Version is the version number of the selected file.
Perhaps the most useful piece of information is fName, the filename of the selected
file.
After everything has been set up, we are ready to invoke the standard get file
package as follows:
MOVE.W #2,-(SP) ;Call SFGetFile through
_Pack3 ;the package manager
After checking good and determining that a successful call has occurred, the only
remaining task is running the selected application.
The routine responsible for running an application is located in the Segment
Loader and is called Launch. The launch routine is unique in the method used to call it.
Unlike the toolbox traps, in which values are passed on the stack, launch is a routine
whose values must be pointed to by an address register. Register based routines such
as this are common in the low level system portion of the Macintosh ROM.
In calling the launch routine, the programmer passes a pointer to the Launch
Pointer Record in A0 [Fig 2]. The first 4 bytes of the LP record (no pun intended...)
consist of a pointer to the filename of the application we want to run. As all Macintosh
programmers must quickly learn, the assembly language equivalent of a pointer is an
Effective Address. In order to get a pointer to the filename, we load its effective
address into address register A1 by the instruction LEA FileName,A1. When we have
the effective address (or pointer) in a register, we are free to store it in the proper
location of the LP record. The last 2 bytes compose a word of data that tells the launch
routine how we want memory allocated to the application. A value of NIL in this
location gives standard memory allocation (as the Finder would), so we do not need to
change it.
After the LP record has been set up and A0 is pointing to it, the trap _Launch is
called and we are finished.
The balance of the program consists of initialization calls to the various
managers and a few QuickDraw traps to display the title of the program. The program
as I have implemented it is functional, but rather spartan in its lack of features and
appearance. No resources were included and there is no use of menus or windows. The
purpose of this article was to describe some interesting parts of the toolbox, not to
reiterate the material that David has described in his column. However, I encourage
you to liven your own versions up by putting some graphics or a description of the
program somewhere on the screen. At least put your name in it and impress your
friends!
;[Missing image]icroFinder Û[Missing image]
;[Missing image][Missing image]
;[Missing image]A startup program that allows [Missing image]
;[Missing image]e user to select the Û[Missing image]
;[Missing image]the application that he wants [Missing image]
;[Missing image] run of those on the disk. [Missing image]
;[Missing image]e 1985. Â[Missing image]
;[Missing image][Missing image]
;[Missing image]© MacTutor by Chris Yerga [Missing image]
;[Missing image] Contributing Editor [Missing image]
;[Missing image]ToolBox & System Traps [Missing image]
.TRAP _InitCursor $A850
.TRAP _InitGraf $A86E
.TRAP _SetPort $A873
.TRAP _BackPat $A87C
.TRAP _DrawString $A884
.TRAP _TextFont $A887
.TRAP _TextSize $A88A
Referenced by (2):